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RESOURCE SCHEDULING IN WORKFLOW MANAGEMENT SYSTEMS 

Field of the Invention 

{0001} The present invention relates to means and a method for 
improving the scheduling of resources within a Workf low-Management - 
System or a computer system with comparable functionality (WFMS) . 

Background 

{0002} A new area of technology with increasing importance is 
the domain of Workf low-Management -Systems (WFMS) . WFMS support the 
modeling and execution of business processes. Business processes 
executed within a WFMS environment control who will perform which 
piece of work of a network of pieces of work and which resources 
are exploited for this work. The individual pieces of work might be 
distributed across a multitude of different computer systems 
connected by some type of network. 

{0003} The product "IBM MQSeries Workflow" (previously called 
IBM FlowMark) represents such a typical modern, sophisticated, and 
powerful workflow management system. It supports the modeling of 
business processes as a network of activities. This network of 
activities, the process model, is constructed as a directed, 
acyclic, weighted, colored graph. The nodes of the graph represent 
the activities, which define the individual tasks that need to be 
carried out. In general, each of the activities is associated with 
a piece of code that implements the appropriate task. The edges of 
the graph, the control connectors, describe the potential sequence 
of execution of the activities. Definition of the process graph is 
via IBM MQSeries Workflow's Flow Definition Language (FDL) or via 
the built-in graphical editor. 
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{0004} The runtime component of the workflow management system 
interprets the process graph by following the prescribed execution 
sequence. For each activity, the runtime component invokes the 
associated piece of code, called activity implementation. When 
invoked, said piece of code obtains the necessary resources and 
carries out the designated work. If the requested resource is not 
available, the piece of code typically waits until it becomes 
available. The execution time of a process is thus composed of the 
time needed by the runtime component of the workflow management 
system for the navigation of the business process (including the 
invocation of the activity implementations), the execution time of 
the activity implementations, and the time the activity 
implementations wait for resources to become available. Thus, the 
wait time contributes significantly to the execution time of 
business processes and represents an important problem awaiting 
solutions for improvements . 

{0005} It should be noted that the meta model MQSeries Workflow 
is using to describe business processes is just a particular meta 
model to do this. Other workflow management systems use other meta 
models for describing business processes; however they all use the 
notion of an activity as the smallest element of a business process 
and the notion of carrying out those activities in some order. 
Despite the difference in models, the problem of having wait times 
when carrying out business processes occurs there as well. 

{0006} Above mentioned execution time problem is even increased 
if multiple activities controlled by the WFMS are competing for the 
same or in general conflicting resources resulting in situations 
where one activity could hinder another activity. In the worst case 
requests for conflicting resources might result even in deadlock 
situations . 

{0007} The invention is based on the objective to improve the 
handling of resources required by activities within process models 
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controlled by a WFMS. More particularly it is an objective to 
improve the execution time of business processes. 

Summary 

{0008} The objectives of the invention are solved by the 
independent claims . Further advantageous arrangements and 
embodiments of the invention are set forth in the respective 
subclaims . 

{0009} The current invention relates to a method and to a system 
for improved scheduling of resources within a Workf low-Management - 
System or a computer system with comparable functionality (WFMS) . 
It is assumed that the WFMS administrates execution of a process 
model of a business process and the process model comprising at 
least one activity. 

The proposed method comprises a first step of determining whether 
the process model is comprising a resource specification associated 
with the activity. The resource specification comprises at least 
one resource identification of a resource required for execution of 
said activity. 

{0010} The proposed method comprises a second step of requesting 
allocation of said resource on behalf of and in advance of starting 
execution of the activity. 

Finally in a third step the method is starting execution of said 
activity. 

{0011} The suggested approach improves significantly the 
processing time (execution time) of a business process. The 
performance gains are most significant especially if the resources 
needed by the individual activities are either scarce resources, 
such as a high-bandwidth line, or offline resources, such as data 
that has been put onto tape and that requires the mounting of the 
tape. The current invention allows to handle resources in the most 
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general meaning of this term, comprising all types of entities 
manageable by a computer system. 

Brief Description of the Drawings 

{0012} Figure 1 shows a business process model represented by a 
process graph according to the state of the art. 

Figure 2 depicts the fine structure of an activity within a WFMS. 

Figure 3 shows the typical steps that are performed when an 
activity within a process graph is being carried out by a WFMS. 

Figure 4 shows a part of a business process with resources required 
by each of the activities/activity implementations. 

Figure 5 shows the important actions of the workflow management 
system when carrying out the part of a business process shown in 
Fig. 4; specific focus is given to the aspect that it is the WFMS 
itself requesting allocation of required resources on behalf of and 
in advance of starting execution of the activities. 

Detailed Description 

{0013} In the drawings and specification there has been set 
forth a preferred embodiment of the invention and, although 
specific terms are used, the description thus given uses 
terminology in a generic and descriptive sense only and not for 
purposes of limitation. It will, however, be evident that various 
modifications and changes may be made thereto without departing 
from the broader spirit and scope of the invention as set forth in 
the appended claims. 

{0014} The present invention can be realized in hardware, 
software, or a combination of hardware and software. Any kind of 
computer system - or other apparatus adapted for carrying out the 
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methods described herein - is suited. A typical combination of 
hardware and software could be a general -purpose computer system 
with a computer program that, when being loaded and executed, 
controls the computer system such that it carries out the methods 
described herein. The present invention can also be embedded in a 
computer program product, which comprises all the features enabling 
the implementation of the methods described herein, and which - 
when being loaded in a computer system - is able to carry out these 
methods . 

{0015} Computer program means or computer program in the present 
context mean any expression, in any language, code or notation, of 
a set of instructions intended to cause a system having an 
information processing capability to perform a particular function 
either directly or after either or both of the following a) 
conversion to another language, code or notation; b) reproduction 
in a different material form. 

{0016} The current invention is illustrated based on IBM's 
"MQSeries Workflow" workflow management system. Of course any other 
WFMS could be used instead. Furthermore the current teaching 
applies also to any other type of system, which offers WFMS 
functionalities not as a separate WFMS but within some other type 
of system. 

{0017} A resource according to the current invention may refer 
to any type of entity which can be managed by a computer system. 
Some simple examples are: CPU cycles, memory, devices, disks and 
the like. 

{0018} The following is a short outline on the basic concepts of 
a workflow management system based on IBM's "MQSeries Workflow" 
WFMS: 

{0019} From an enterprise point of view the management of 
business processes is becoming increasingly important: business 
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processes or process for short control which piece of work will be 
performed by whom and which resources are exploited for this work, 
i.e. a business process describes how an enterprise will achieve 
its business goals. A WFMS may support both, the modeling of 
business processes and their execution. 

{0020} Modeling of a business process as a syntactical unit in a 
way that is directly supported by a software system is extremely 
desirable. Moreover, the software system can also work as an 
interpreter basically getting as input such a model: The model, 
called a process model or workflow model, can then be instantiated 
and the individual sequence of work steps depending on the context 
of the instantiation of the model can be determined. Such a model 
of a business process can be perceived as a template for a class of 
similar processes performed within an enterprise; it is a schema 
describing all possible execution variants of a particular kind of 
business process. An instance of such a model and its 
interpretation represents an individual process, i.e. a concrete, 
context dependent execution of a variant prescribed by the model. A 
WFMS facilitates the management of business processes. It provides 
a means to describe models of business processes (build time) and 
it drives business processes based on an associated model 
(runtime). The meta model of IBM's WFMS MQSeries Workflow, i.e. the 
syntactical elements provided for describing business process 
models, and the meaning and interpretation of these syntactical 
elements, is described next. It should be noted that the meta-model 
of MQSeries Workflow is just a particular way of representing 
business processes; other meta-models, such as Petri Nets do exist. 
It should however also be noted that process graphs are the typical 
way of representing business processes in all of these approaches. 

{0021} In MQSeries Workflow business processes are modeled as 
directed, acyclic, colored, and weighted graphs. The nodes of the 
graph represent the activities that need to be carried out and the 
edges of the graph the control connectors that describe the 
potential sequence in which the activities are to be carried out. 
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{0022} Thus, a process model is a complete representation of a 
business process, comprising a process diagram and the settings 
that define the logic behind the components of the diagram. 
Important components of an MQSeries Workflow process model are: 

■ Processes 

■ Activities 

■ Blocks 

■ Control Flows 

■ Connectors 

■ Data Containers 

■ Data Structures 

■ Conditions 

■ Programs 

■ Staff 

Not all of these elements will be described below. 

{0023} Activities are the fundamental elements of the meta 
model. An activity represents a business action that is from a 
certain perspective a semantic entity of its own. 

{0024} It should be noted that the distinction between activity 
and activity implementation must not necessarily be reflected in 
the underlying meta model; however from a conceptual point of view 
each activity is associated with an activity implementation. The 
activity implementation is typically a piece of code that performs 
the necessary action associated with the activity. Insofar the 
activity is the abstract representation of an activity 
implementation performing that particular business activity. 

{0025} The flow of control, i.e. the control flow through a 
running process determines the sequence in which activities are 
executed. The MQSeries Workflow workflow manager navigates a path 
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through the process that is determined by the evaluation to TRUE of 
start conditions, exit conditions, and transition conditions. 

{0026} As an example of such a process model Fig. 1 shows 
schematically the structure of such a process graph. Activities (Al 
up to A5) are represented as named circles; the name typically 
describes the purpose of the activity. Activities come in various 
flavors to address the different tasks that may need to be 
performed. They may have different activity implementations to meet 
these diverse needs. Program activities are performed by an 
assigned program, process-activities like for instance 100 are 
performed by another process 101, and blocks like for instance 102 
implement a macro 103 with a built-in do-until loop. Control 
connectors P12, P45 are represented as arrows; the head of the 
arrow describes the direction in which the flow of control is 
moving through the process. For instance, the control connector 110 
defines that activity Al 104 should be followed by activity A2 106. 
Transition conditions, such as pl2 120, determine whether the 
control connector is actually been followed in a particular process 
instance. The activity where the control connector starts is called 
the source activity; where it ends is called the target activity. 

{0027} When more than one control connector leaves an activity, 
this indicates potentially parallel work. Activities that have no 
incoming control connectors, such as activity Al 104, are called 
start activities; activities that have no outgoing control 
connector, such as activity A5 105, are called end activities. 

{0028} All processes and all activities are associated with 
context. Context is defined as the data that is passed to the 
process or activity when invoked. A process or an activity can also 
return data. The data that is passed to the process or activity is 
called the input contain r; the data that is returned by a process 
or activity is called the output container. 
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{0029} The process input container typically provides the 
overall context of a business process. It determines how a specific 
business process should be executed by defining which paths should 
be taken through the business process. For a loan process, for 
example, the process input container contains the number of the 
customer who requests a loan. The activity input container provides 
the appropriate context for the execution of the activity; for 
example, let's say that the input container provides a customer 
number. The program that implements the activity to access the 
customer database and retrieve all information associated with this 
customer number could use the customer number. The activity would 
then return the appropriate information in the output container. 
The output container can then be used by later activities or to 
further define which paths the business process should be taken. 

{0030} Fig. 2 shows the inner structure of program activities 
and indicates what is being done in the individual parts of an 
activity. 

{0031} As the processing of the incoming control connectors with 
their associated logical predicates pi, pn is not of importance 
for the current invention a detailed description of this feature is 
skipped. 

{0032} The query on organization database (200) and proper 
implementation (210) form the core of the activity. 

{0033} The query against the organization database specifies in 
organizational terms which employee should carry out the activity. 
Since people in the organization are typically called staff, this 
query against the organizational database is also called a staff 
query. When the activity is ready for processing, this query is 
carried out and returns a set of users that are assigned to the 
activity. The process of finding the appropriate people is called 
staff resolution. 
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{0034} The proper implementation specifies what is used to carry 
out the activity and how it is to be carried out. The 
implementation could be a program that is executed or another 
process that is invoked. 

{0035} The combination of the proper implementation and the 
query against the organization database is called a task. When the 
activity needs to be carried out, staff resolution returns the list 
of users that need to be assigned to the activity. Multiple users 
may be selected for an activity based on the theory that the more 
people know that a work request requires their action, the more 
likely it is that the work request is performed soon. The workflow 
management system ensures that eventually only one user performs 
the requested work. The workflow management system then builds for 
each user a work item consisting of the user identification and the 
proper implementation. A user then uses the work item to launch the 
appropriate implementation. Facilities provided by the workflow 
management system allow the user to organize work items with the 
same characteristics into work lists (240) . 

{003 6} Fig. 3 illustrates the typical execution of a program 
activity. It is assumed that the activity is a manual activity that 
means that a user must start it (in contrast to automatic ones, 
which can be executed by the system without any user interaction 
and thus are started by the WFMS automatically) . 

{0037} When the user clicks on a work item (340) on one of his 
work lists (350), the workflow management system builds the input 
container (310) for the activity (300) . Then, the workflow 
management system invokes the program (320), i.e. the activity 
implementation. The program obtains the necessary information from 
the input container, performs the necessary actions such as 
interacting with the user or accessing a database (360), puts any 
new data into the output container (330) , and then returns to the 
workflow management system. The workflow management system 
evaluates the exit condition (250); if the exit condition evaluates 
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to true, navigation continues. If the exit condition fails, the 
work item reappears again on the work list so that the user can 
continue the activity later. 

{0038} If the activity is an automatic activity, the same 
actions are performed by the workflow management system. However, 
the activity implementation is started automatically. 

{0039} The activity implementations when invoked need resources, 
such as memory, CPU cycles, files, or many other resources; in 
general a resource might represent any entity manageable by a 
computer system. Some of them might be used directly by the 
activity implementation, such as CPU cycles and memory; others 
might be used indirectly, such as a table maintained by a 
relational database management system. 

{0040} All resources are managed by an execution environment. 

This execution environment may be anything from a single processor 
operating system, an application operating system, a fully 
distributed operation system, or even a combination thereof. 
Typically the execution environment forms the context wherein which 
an activity is being executed. 

{0041} It is the responsibility of this execution environment to 
provide a platform for the execution of activity implementations 
and all the applications being invoked as the result of running an 
activity implementation. It is also the responsibility of the 
execution environment to provide the computing resources, such as 
CPU cycles, disks, or memory or other types of resources. 

{0042} Simple execution environments make resources available to 
an exploiter when requested by an application; advanced execution 
environments provide the capability to request the scheduling of 
resources at any time. When the application then needs the 
resources, even for example to run itself, the resources will be 
readily available. This is particularly helpful, if the resources 
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are not available right away and preparation steps are required, 
such as the mounting of a tape. 

{0043} When the workflow management system invokes the activity 
implementation, it does this typically by asking the execution 
environment to activate the activity implementation. The execution 
environment allocates appropriate resources on request, such as 
memory, and then proceeds executing the activity implementation by 
allocating CPU cycles to the activity implementation. 

{0044} If a resource is not available, the execution 
environment, depending on its capabilities, takes a particular 
action. These actions typically depend on the type of resource and 
on a set of policies, which can in general be set by system 
administrators. For example, if more CPU cycles are needed than 
there are available, a policy of prioritization is applied. 
Programs with higher priority are assigned more CPU cycles than are 
assigned to programs with a low priority. Another option for the 
operating system would be to refuse to run the requested program 
and return an appropriate indicator to the requestor. Certain types 
of resources are typically offline, such as tapes. Those resources 
must first be made online before they can be used; for example, a 
tape must first be mounted before it can be used. 

{0045} Waiting for resources should be avoided if execution of a 
task needs to be performed as quickly as possible. It is 
particularly important if the overall task consists of a set of 
smaller tasks, which is the usual case in applications that are not 
just trivial. If in a business process with 10 individual tasks 
each task takes 10 minutes, then the execution of the business 
process takes 100 minutes. If one would need to wait 10 minutes for 
each activity to have the resources available, then the total 
execution time of the business process would be 200 minutes; twice 
as much as would be without waiting for resources. 
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{0046} Above mentioned impact to execution time is even 
increased if multiple tasks are competing for the same or in 
general conflicting resources resulting in situations where one 
task could hinder another task. In the worst case requests for 
conflicting resources might result even in deadlock situations. 

{0047} When an activity is being carried out during processing 
of a business process, the workflow management system invokes for 
an activity a specified piece of code. Invoking means requesting 
from the underlying execution environment, such as the operating 
system or an application server, the execution of the specified 
piece of code. When invoked, said piece of code obtains the 
necessary resources and carries out the designated work. If the 
requested resource is not available, the piece of code typically 
waits until it becomes available; other options may be to not honor 
the request at all. 

{0048} As a first observation of the current invention, the 
problem of activities being idle and waiting for a resource can be 
solved under the following two conditions: the business process is 
being carried out by a workflow management system and the execution 
environment provides the capability to claim resources in advance 
(classified earlier as an advanced execution environment) . 

{0049} The present invention proposes a mechanism to improve the 
processing of activities by having the workflow management system 
scheduling on behalf of the activities the resources needed by the 
activities well in advance. Scheduling means requesting from the 
execution environment the making available of a certain set of 
resources. As a further observation this scheduling by the workflow 
management system is enabled and improved based on information 
provided by the designer of the business process and/or based on 
information collected by the workflow management system during 
previous execution of business processes. For that purpose it is 
suggested to associate within a process model resource 
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specifications with activities and these resource specifications 
comprise identifications of resources required for execution of the 
activities . 

{0050} As a further observation it is noted that based on these 
resource specifications within a process model it is becoming 
possible for a workflow management system to analyze the sets of 
resources required by different activities for conflicting resource 
requirements. The workflow management system for instance can 
determine situations where activities are competing for the same 
resources or where activities might create deadlock situations with 
respect to their resource requirements . Thus the resource 
specifications enable a workflow management system to determine 
overall resource scheduling plans which avoid resource conflicts 
and thus result in less or no hindering between different 
activities. The overall result achieved is improved execution times 
and increased throughput of the system. 

{0051} It is thus suggested that each activity within a business 
process is associated with the set of resources that it requires. 
This association is defined in a new specification, called resource 
specification, which is made part of the process model. Typical 
specifications would comprise an identification of the types of 
required resources as well as the quantities of the resources such 
as the amount of CPU time needed, the amount of memory needed, the 
amount of temporary disk storage that needs to be allocated, the 
files and database the activity accesses and the like. Further 
suggested data comprised within the resource specifications relates 
to the identification of the execution environment where to request 
and allocate a particular resource as well as an assumed waiting 
time period specifying the time required after an allocation 
request until said resource actually becomes available. The 
workflow management uses this information to develop a resource 
scheduling plan when to allocate which resource for which activity 
instance. The resource scheduling plan can be determined by the 
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workflow management system such that resource conflicts can be 
avoided. 

{0052} Fig. 4 shows an example of a workflow that contains three 
activities A (410), B (420), and C (430). Each activity has a set 
of runtime properties assigned to it, which represent the 
associated resource specifications (translated into a human 
readable representation) reflecting the required resources, the 
amount /quantity of resource required, the assumed waiting time 
period (specifying the time required after an allocation request 
until said resource actually is available) , the expected execution 
time for the particular activity and the like. Activity A (410) 
executes for 15 minutes, requires 300 GB of memory, and needs a 
tape to be mounted (440) . Scheduling of the memory takes 5 minutes; 
mounting of the tape takes 10 minutes. Similar information (450, 
460) is defined for activities B and C. 

{0053} If the business process in Fig. 4 is executed without any 
pre-scheduling of resources, the total execution time of the 
business process is 58 minutes 28(15+7+6) minutes for carrying out 
the activities, 30 (10+5+10+5) minutes for scheduling the 
resources . 

{0054} As an important observation of the current invention the 
total execution time can be significantly reduced if the workflow 
management system schedules (on behalf of the activity) the 
resources before it is actually used by the invoked activity 
implementation. Fig. 5 shows how such a resource scheduling plan 
would look for the business process shown in Fig. 4; Fig. 4 is a 
graphical representation of this resource scheduling plan, which of 
course also can be represented in other notations and forms. The 
workflow management system uses the information associated with 
each activity (this information is comprised within the resource 
specification associated with the activity as described above) to 
determine when the appropriate resource must be requested from the 
underlying infrastructure (typically the operating system) . 
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{0055} It follows from Fig. 5 that ahead of starting activity A 
under "Start Activity A" the workflow management system allocates 
the tape resource under "Tape For A" on behalf of that activity. 

{0056} The numbers within Fig. 5 represent the elapsed time in 
minutes from the start of the business process under "Start 
Business Process". As the associated resource specification 
indicates an assumed waiting time period of 10 minutes (440) 
required after an allocation request until the tape is actually 
available the resource scheduling plan defines that the tape 
resource is requested at least 10 minutes ahead of starting 
activity A. In a similar manner the resource memory is requested 
under "Memory For A" at least 5 minutes (this represents the 
corresponding assumed waiting time period) before starting activity 
A; to minimize resource conflicts relating to the resource memory, 
the workflow management system schedules an allocation request not 
together with that for the resource tape (which in principle would 
be possible also) because this would exclude other exploiters of 
that particular resource for additional 5 minutes. 

{0057} As follows from the resource scheduling plan in Fig. 5 
the workflow management system is already engaged in requesting the 
resource disk under "Disk For B" even though preceding activity A 
is still executing; this represents also one of the optimization 
features of the current invention. The resource specification of 
activity B defines a resource requirement for resource disk with an 
assumed waiting time period of 10 minutes (450) , therefore the 
workflow management system is requesting this resource at least 10 
minutes ahead of starting activity B at "Start Activity B" . 

{0058} According to the example workflow of Fig. 4 the workflow 
management system would start after successfully executing activity 
B followed by activity C as a successor activity. As follows from 
the resource scheduling plan in Fig. 5, the workflow management 
system is already engaged in requesting the resource tape under 
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"Tape For C" even though preceding activity B is still executing 
and has not received its end of execution at "End activity B" . The 
resource specification of activity C (460) defines a resource 
requirement for resource tape with an assumed waiting time period 
of 5 minutes, therefore the workflow management system is 
requesting this resource at least 5 minutes ahead of starting 
activity C at "Start Activity C" . 

{0059} As shown in Figure 5, the total execution time is 38 
minutes representing the significant advantage over the required 
total execution time of 58 minutes according to the prior art 
approach . 

{0060} The quality and precision of the suggested technology 
depends on the quality and procession of the data comprised within 
the resource specifications (like the assumed waiting time periods) 
associated with the activities. The more accurate this data is, the 
more accurately can the workflow management system schedules the 
resources . The accuracy of the numbers can be improved through a 
set of optional actions that the workflow management system 
performs as an ongoing process when carrying out business 
processes : 

■ By monitoring and collecting the actual time it takes from 
scheduling a required resource until that resource is 
actually available, i.e. determining the actual waiting time 
period until the requested resource becomes available. 
Various strategies could be exploited then how this actual 
waiting time period determined by monitoring could be used by 
the workflow management system. One possibility would be to 
use the actual waiting time period as a more current and new 
assumed waiting time period within the above outlined 
resource scheduling process. Another possibility would be to 
take a multitude of such monitored actual waiting time 
periods and apply some statistical measure on it for 
determining a new assumed waiting time period. For instance 
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one could use the mean value of such a set of monitored 
actual waiting time periods as a current assumed waiting time 
period. Of course other statistical measures are possible 
also . 

■ By monitoring and collecting the actual time it takes to 
carry out an activity, i.e. determining the actual execution 
time of an activity. 

{0061} In all of these cases the current invention further 
suggests that the workflow management system use this monitored 
data to update the corresponding resource specifications within the 
process model automatically. 

{0062} Depending on the structure of the business process and 
the costs associated with unnecessary scheduling of resources and 
the amount of money paid for the business process, further 
optimizations could be performed. 

{0063} Further optimization could also be performed by having 
the workflow management system scheduling its own resources the 
same way as scheduling the resources for the activity 
implementations . 



